<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Learning Journal',
	'<{subtitle}>' => 'CS 2204: Communications and Networking',
	'<{copyright year}>' => '2018',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="Unit1">
	<h2>Unit 1</h2>
	<p>
		Each network layer needs a way to identify the machine the message needs to be sent to.
		Otherwise, there&apos;s no way for the machine to know where to transmit the message to.
		If this isn&apos;t well-implemented when the protocol is set up, some machines may be unreachable, as there&apos;s no way to specify that the communication should be sent to that machine.
	</p>
	<p>
		On the lowest level, the rules of communication must be known.
		Simplex (unidirectional), half-duplex (unidirectional, but with the direction able to switch), or duplex (bidirectional) communication may be allowed.
		If not properly dealt with, the line may be misused.
		For example, the machine might try to use an incoming-only line to transmit by, or might try to use a half-duplex line while messages are incoming.
		This could lead to message loss or message corruption.
	</p>
	<p>
		Mechanisms must be in place to detect and correct errors.
		Otherwise, errors caused by flaws in the physical structures of the computers and their communication mediums will go undetected.
		Data will degrade.
	</p>
	<p>
		Packets may arrive in an unintended order.
		Protocols should provide a way to correctly put the data pieces back together regardless of order received.
		If this isn&apos;t accounted for, messages may end up scrambled when reassembled.
	</p>
	<p>
		Differing speeds between a sender and receiver can be a problem if the sender is the faster one.
		In such cases, the sender often needs to slow its transmission rate.
		If not accounted for, the receiver may have to drop packets to keep up.
	</p>
	<p>
		Some processes have a limit to the size of message they can handle.
		This is one reason why messages are broken up into segments, packets, or frames.
		If this issue isn&apos;t addressed, overly-long messages may be sent, which will likely be rejected by the receiver.
	</p>
	<p>
		In a redundant network, multiple paths from a source to a destination will often exist.
		If this isn&apos;t accounted for properly, a message may not reach its destination, as the machines won&apos;t know which path to send the message along.
	</p>
</section>
<section id="Unit2">
	<h2>Unit 2</h2>
	<p>
		The cyclic redundancy check is a 32-bit hash added to Ethernet packets to allow for detection of damaged bits.
		This hash isn&apos;t added by any software, but rather, by the networking hardware itself (Dordal, 2014).
		The purpose of a hash is simple.
		An algorithm is used to compute a hash based on some input data.
		The algorithm will always output the same hash if the same input is used, but if even one bit is flipped, a very different hash value will be computed.
		At the receiving end, the same hashing function is used to compute the hash value again, and this newly-computed value is compared to the received hash value.
		If the sent hash doesn&apos;t match the computed hash at the receiving end, it can be determined that the packet has in some way been damaged.
		It&apos;s worth noting that with any hash-based error-detection system such as this, the hash won&apos;t match if the payload data is damaged, but it also won&apos;t match if the checksum data is damaged instead.
		It doesn&apos;t matter which comes through incorrectly; a mismatch will be detected either way.
	</p>
	<div class="APA_references">
		<h3>References:</h3>
		<p>
			Dordal, P. (2014, March). 2 Ethernet - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="http://intronetworks.cs.luc.edu/current/html/ethernet.html"><code>http://intronetworks.cs.luc.edu/current/html/ethernet.html</code></a>
		</p>
	</div>
</section>
<section id="Unit3">
	<h2>Unit 3</h2>
	<p>
		The original setup of the telephone network isn&apos;t at all what I expected.
		Each telephone needing a direct line to each other telephone a person wanted to call ... wires draped over buildings by private citizens ...
		I&apos;ve known the modern telephone system is a mess for over a decade, but I didn&apos;t realise just how much worse it was in the past.
		What if you wanted to be in touch with someone across town?
		You&apos;d need to get permission from everyone in between to drape your wire over their property, and I&apos;m not even sure what you&apos;d do to get your wire across streets.
		Maybe with less regulation in those days (with telephones being so new, I imagine regulations on them hadn&apos;t been established as much yet), makeshift telephone poles owned by private citizens propped wires up enough to let cars pass beneath.
	</p>
	<p>
		The book mentions that people want to check their email and surf the Web on the go, and explains that thus, there&apos;s a growing interest in wireless telephony.
		Telephony though, by definition, does only voice.
		You can&apos;t check your email or surf the Web using telephony.
		In reality, this explains a growing interest in wireless networking, but not a growing interest in wireless telephony.
		There&apos;s a <strong>*huge*</strong> difference.
		It was also interesting to see that the United States, who frequently does things the wrong way, started out doing wireless telephony in a sane way.
		To be specific, we set up a single standard for 1G mobile communication.
		But then, we had to go and allow nonstandardisation in later generations.
		It just goes to show that even on the rare occasion we don&apos;t get things wrong the first time, we try again and make sure to mess things up.
		We&apos;re such a terrible country.
		The fact that most United States citizens settle for noxious postpaid service is pretty stupid too.
		Elsewhere in the world, people don&apos;t take that, and go with better, prepaid options.
		At least the United States <strong>*has*</strong> prepaid options.
		If we didn&apos;t, I&apos;d&apos;ve never even started using a mobile device.
		It was interesting too to learn the meaning of the term &quot;cellular device&quot;.
		The term always seemed strange to me, as I wasn&apos;t sure how mobile devices related to cells.
		I&apos;d previously thought that perhaps it had to do with the structure of the batteries or something.
		Most of the important stuff on technical aspects of mobile device networks aside from directional antennas and $a[GSM] multiframes were just review for me though.
		I learned most of it when I was trying to figure out how to get an inherently-$a[GSM] model of device onto a $a[CDMA] network.
		Long story short, you can&apos;t do it.
		Back then though, I wasn&apos;t even aware of the competing standards yet.
	</p>
	<p>
		Hidden nodes and collisions that only affect receivers within range of both transmitters was a new concept to me.
		It makes perfect sense, but isn&apos;t something I&apos;d thought about before.
		Multipath interference is something I hadn&apos;t thought about either.
		The book mentions the need for Wi-Fi transmissions to be encrypted, but there&apos;s a fatal flaw in the encryption system used in modern Wi-Fi.
		Namely, there&apos;s no way to encrypt transmissions without preventing outsiders from using the access point.
		Open Wi-Fi is a valuable resource.
		There should be a way for the Wi-Fi central node to use a different, dynamic encryption key for each user for security, without blocking users that don&apos;t have an initial password.
		Until this problem is solved, my Wi-Fi network will <strong>*always*</strong> remain unencrypted.
		That said though, I&apos;m a $a[Tor] user.
		That means all my traffic is behind three (four when using $a[TLS]) layers of encryption anyway.
		Wi-Fi level encryption would be a fourth (or fifth) encryption layer, which one could argue is unneeded.
		Perhaps some sort of open Wi-Fi access point with encrypted connections could be set up using the Extensible Authentication Protocol; this would be a hacky workaround for a missing feature though, and not an actual solution.
	</p>
</section>
<section id="Unit4">
	<h2>Unit 4</h2>
	<p>
		For the most part, the course has been great and I&apos;m learning a lot of new things.
		My only complaint is the poor format of the textbook.
		All the diagrams use white text on a transparent image background.
		Pair that with the while background of the webpage, and all the diagrams become unreadable.
		If I wasn&apos;t a computer science major, it&apos;d be a debilitating problem.
		However, as I know what I&apos;m doing with $a[CSS] and $a[XHTML], it&apos;s only a mild nuisance; I simply edit the code of the page to give it a grey background behind the images and they become fully readable.
		Still, it&apos;s a bizarre choice made by the book&apos;s author, and I can&apos;t help but feel it was an accident.
		Maybe some other colour had been used as the background colour of the page in the past and a later update to the $a[CSS] broke things.
	</p>
	<p>
		The main problem I&apos;m facing is one of motivation.
		I used to be very enthusiastic about my studies, and I got everything completed early in the week.
		However, after the unnecessary threats from the school a few terms ago ... the joy of learning&apos;s been drained from me.
		My morale is down; I struggle to stay on task; and instead of coursework being my hobby that I work on every chance I get, it&apos;s something I now mainly work on on my days off from work.
		My days off lately have been Tuesday and Wednesday, so my coursework gets done pretty much in the couple days before it&apos;s due.
	</p>
	<p>
		Am I able to keep up?
		Yeah, I&apos;m keeping up.
		Not as well as I should be, but I&apos;m making it through.
		Am I using the course forum?
		No, not really.
		I typically turn to the course forum when I&apos;m facing a problem; when I don&apos;t understand the material, when something technical is broken, et cetera.
		The material isn&apos;t too difficult though and the only break I&apos;ve noticed is one I can bandage on my end, even though I can&apos;t actually fix it.
		No one else in class is going to be able to actually fix the background of the webpage any better than I can though.
		The editing of the local copy of the page is probably the only solution any of us would have, and it&apos;s plenty functional enough to get by with.
	</p>
</section>
<section id="Unit5">
	<h2>Unit 5</h2>
	<p>
		The fundamental difference between a switch (at layer 2) and a router (at layer 3) is that one connects nodes into a network, while the other connects existing networks (Cisco, n.d.).
		A switch isn&apos;t absolutely necessary to form a network, but it acts as a central controller to make network formation easier and operation more efficient.
		A router, on the other hand, connects switch-controlled networks to form a bigger network, such as the Internet we all know and love.
	</p>
	<div class="APA_references">
		<h3>References:</h3>
		<p>
			Cisco (n.d.). What Is a Network Switch vs. a Router? - Cisco. Retrieved from <a href="https://www.cisco.com/c/en/us/solutions/small-business/resource-center/connect-employees-offices/network-switch-what.html"><code>https://www.cisco.com/c/en/us/solutions/small-business/resource-center/connect-employees-offices/network-switch-what.html</code></a>
		</p>
	</div>
</section>
<section id="Unit6">
	<h2>Unit 6</h2>
	<h3>$a[TFTP]</h3>
	<p>
		If the client changes port number while the server does not, old duplicate packets will never arrive to the client&apos;s process.
		These packets will still arrive at the client machine, but because the client machine has no process running on that particular $a[UDP] port any more, the packets will simply be dropped.
		The book does not explicitly state this, but a basic understanding of what ports are even used for makes this obvious.
		Of course, if a new process has started listening on this port on the client machine, that client process will unexpectedly receive $a[TFTP] packets, which it will probably process incorrectly or fail to process altogether.
	</p>
	<p>
		If the server changes ports but the client doesn&apos;t, old duplicate packets will in fact be able to make it to the client process.
		However, the client process will recognise that the server port number (which is included in the header) is incorrect and will treat the packets as invalid.
		In this case, the client will send an error packet to the server informing it that the &quot;transfer $a[ID]&quot; is invalid; the &quot;transfer $a[ID]&quot; actually being the port number (Dordal, 2014).
	</p>
	<h3>Non-cumulative</h3>
	<p>
		The problem states that replies can be sent in any possible order, regardless of the order in which the requests are received, and more importantly, regardless of the order in which the requests are sent.
		For this reason, acknowledgements being cumulative makes no sense, and would be a poor design decision that would introduce errors.
		Instead, each acknowledgement needs to confirm that a single, specific reply was received.
	</p>
	<p>
		If an acknowledgement is lost, the server has no way to distinguish it from the case of the reply being lost.
		The server should therefore try resending the reply.
		However, there also needs to be some sort of timeout, in case the reply is never going to come, for some reason or another.
		For example, the client may have crashed, given up waiting (timed out), or already received the information and sent the acknowledgement.
		Of course, if the client receives the packet and sends the acknowledgement, the client should probably wait a while (entering a dally state) to see if the server tries to resend the packet, but the dally state might end before the repeat packet arrives, which is why the server too needs to be able to time out.
	</p>
	<div class="APA_references">
		<h3>References:</h3>
		<p>
			Dordal, P. (2014). 11 UDP Transport - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/udp.html"><code>https://intronetworks.cs.luc.edu/current/html/udp.html</code></a>
		</p>
	</div>
</section>
<section id="Unit7">
	<h2>Unit 7</h2>
	<p>
		If a SYN request comes, but the port it&apos;s sent to isn&apos;t being listened on, the application sending the SYN request will receive a $a[TCP] RST message (Dordal, 2014).
		My understanding is that this RST message serves as an error indicator that means that the connection was refused, but that no further error message beyond the $a[TCP] RST will be received by the application that attempted the connection.
	</p>
	<div class="APA_references">
		<h3>References:</h3>
		<p>
			Dordal, P. (2014). 12 TCP Transport - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/tcp.html"><code>https://intronetworks.cs.luc.edu/current/html/tcp.html</code></a>
		</p>
	</div>
</section>
<section id="Unit8">
	<h2>Unit 8</h2>
	<h3>$a[DNS]</h3>
	<p>
		$a[DNS] is a vital part of many network systems.
		The Web, email, even gaming ...
		They all use $a[DNS].
		With that in mind, there&apos;s no doubt that the lack of recovery of lost packets in $a[DNS], seeing as $a[DNS] is built on $a[UDP] instead of $a[TCP], is a problem.
		That said, with $a[DNS] so frequently used and not requiring much data to be transferred in each query/response, using $a[UDP] instead of $a[TCP] saves a lot of overhead.
	</p>
	<p>
		Back to the question at hand, $a[DNS] is actually able to be used over $a[TCP] or $a[UDP]; it&apos;s not limited to just $a[UDP] as the question claims.
		When used over $a[UDP] though, a $a[DNS] client will re-attempt a query if it doesn&apos;t get a response, but usually no more then four times (Bernstein, n.d.).
		If the query fails four times, there&apos;s probably a networking issue, and $a[TCP] isn&apos;t going to help with that, so lack of $a[TCP] features isn&apos;t going to save your query at that point.
	</p>
	<h3>Vacation reply trap</h3>
	<p>
		I didn&apos;t see any mention of vacation replies in this week&apos;s reading material, so I&apos;m unsure of the context of this question.
		The term &quot;vacation reply&quot; could refer to automated replies on any sort of asynchronous messaging system; or even several types of synchronous messaging systems.
		Usually, I hear the term used to refer to email-related auto-replies though, so I&apos;ll discuss vacation reply loops in that context.
	</p>
	<p>
		When two email servers start sending a series of replies to one another, it&apos;s what&apos;s known as an email loop.
		As Wikipedia mentions, one cause of such a loop is vacation auto-responders (Wikipedia, 2018).
		As to how long the loop will persist, it really depends on the configurations of both servers.
		Either side could end the loop at any time by simply not replying.
		If either side&apos;s storage quota fills with these bogus responses, that side will have nothing to reply to and the loop will terminate.
		With unlimited disk space, the loop could continue forever.
		Additionally, there are anti-loop measures that can be coded into the software of the servers.
		For example, special headers can be used to indicate that a letter is a pre-generated reply.
		If the other server is aware of such a header, it can simply ignore the latter instead of automatically responding to it.
		In other words, if both servers conform to such a standard, the loop won&apos;t begin in the first place.
		This does require compliance on both ends though.
		Another measure, and one that doesn&apos;t require both servers to work together, is to simply set a limit to how many (or how often) the autoresponder will respond to letters from a given user.
		Hit that limit, and the loop terminates.
		For example, if your autoresponder will only reply to one email per sender per day, it doesn&apos;t matter how badly the other party&apos;s autoresponder is configured.
		You send a letter to them, their responder replies, your responder replies, theirs replies again, and your responder ignores this final auto-reply, so only three automatic replies were sent over the network instead of the potential millions.
	</p>
	<p>
		Short of disk limitations and anti-loop measures though, yes, the loop would continue indefinitely until one party returned from vacation and turned off their autoresponder.
	</p>
	<h3><code>Content-Type</code> headers</h3>
	<p>
		The question asks why Web pages are prefixed with $a[MIME] headers.
		Being a Web person, this is something I&apos;ve dealt with quite a bit.
		However, $a[MIME] stands for &quot;Multipurpose Internet Mail Extensions&quot;.
		In other words, $a[MIME] headers are for email, not the Web!
		People commonly <strong>*misuse*</strong> the term &quot;$a[MIME]&quot; or even &quot;$a[MIME]-type&quot; to refer to $a[HTTP] <code>Content-Type</code> headers.
	</p>
	<p>
		$a[HTTP] <code>Content-Type</code> headers are used to inform the client as to what file type is being transmitted.
		That way, the client knows how to process it.
		Some types of files have data types that can be easily identified.
		For example, many image types such as $a[PNG] and $a[JPEG] have predictable opening sequences of octets.
		However, other file types don&apos;t have such indicators in their encoding.
		For example, $a[XML] (including $a[XHTML]), $a[CSS], and JavaScript are all encoded the same way: as plain text.
		Well-written $a[HTML] can even be indistinguishable from $a[XHTML] with certain features omitted.
		The <code>Content-Type</code> header allows the client to know how the server wants the file to be interpreted.
		There could be a hard-coded file extension reader put in the client instead, but even the file extension isn&apos;t a reliable way to detect file type.
		For example, a <code>.php</code> extension refers to a $a[PHP] script file on the server side.
		But the server doesn&apos;t send the script, it sends the output of the script.
		So based on file extension, what should the client treat this file as?
		There&apos;s no way to know without the <code>Content-Type</code> header!
		The output could be $a[HTML], as is the case usual, but it could be $a[XHTML] (I always use $a[XHTML], never $a[HTML]) or even an image of some sort!
		Next, we have the case of directory indexes.
		The file name isn&apos;t even known.
		It could be <code>index.xhtml</code>, but it could also be <code>index.html</code>, <code>no-index.png</code>, or anything else.
		The <code>Content-Type</code> header is simply the most reliable way to ensure all clients understand the sent file in the same way; or at least, ensure all reasonable (read: standards-compliant) clients understand the file the same way.
		If any client <strong>*doesn&apos;t*</strong> interpret the file as being of that sent type (I&apos;m looking at you, Internet Explorer), it&apos;s that client in the wrong and this cannot be blamed on the server.
		The server was unambiguously clear in what the file was to be interpreted as through use of the <code>Content-Type</code> header.
	</p>
	<h2>Firewall issues: $a[VoIP] versus audio streaming</h2>
	<p>
		I couldn&apos;t find anything that addressed the issue of firewall problems specific to $a[VoIP] or audio streaming, either in the assigned reading or elsewhere.
		As far as I can tell, the only issue would be a misconfigured firewall, blocking something you didn&apos;t want blocked.
		In either case, you&apos;re trying to read data from an audio stream over the network; the only difference with $a[VoIP] is that $a[VoIP] has <strong>*two*</strong> audio streams, one in each direction.
	</p>
	<div class="APA_references">
		<h3>References:</h3>
		<p>
			Bernstein, D. J. (n.d.). Notes on the Domain Name System. Retrieved from <a href="https://cr.yp.to/djbdns/notes.html"><code>https://cr.yp.to/djbdns/notes.html</code></a>
		</p>
		<p>
			Wikipedia. (2018, March 28). Email loop. Retrieved from <a href="https://en.wikipedia.org/wiki/Email_loop"><code>https://en.wikipedia.org/wiki/Email_loop</code></a>
		</p>
	</div>
</section>
END
);
